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LOW COST, OPEN APPROACH FOR VEHICLE SOFTWARE 
INSTALLATION/UPDATING AND ON-BOARD DIAGNOSTICS 

FIELD OF THE INVENTION 
[0001] The present invention relates to vehicle software installation, 
upgrade, and diagnostic systems and methods, and particularly relates to an 
open architecture for transferring vehicle software and diagnostic information 
between vehicle processors and an external processor using a portable memory 
device. 

BACKGROUND OF THE INVENTION 
[0002] Today's vehicles typically have a specialized assembly line 
diagnostic link (ALDL) provided under the dash. Today's vehicle software 
installation process during assembly typically requires that a cable be inserted 
into the ALDL and that the vehicle remain in place for some time. Alternatively, a 
portable, external processor temporarily attaches to the vehicle steering wheel as 
the vehicle moves down the assembly line and connects to the ALDL. Post- 
assembly vehicle software upgrade processes therefore require dealers to have 
a dedicated external processor with a specialized communication port. Similarly, 
repair procedures typically require technicians to have portable, handheld 
diagnostic processors with specialized communication ports. These standard 
systems and methods suffer from utilization of a slow speed proprietary serial 
bus that must be physically connected to the on-board communications port for a 
potentially lengthy period of time. 
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[0003] The need remains for a system and method that lower costs 
while increasing flexibility. The need also remains for a smooth migration path as 
newer, faster, cheaper vehicle buses become the industry standard. The present 
invention fulfills these needs. 



SUMMARY OF THE INVENTION 
[0004] A vehicle software installation, upgrade, and diagnostic system 
for use in vehicle assembly, upgrade, and repair, includes a portable memory 
device, such as a USB flash disk. The device receives diagnostic information via 
an open architecture communications port of a vehicle, such as a USB port. An 
external processor has a complimentary open architecture communications port 
and is adapted to receive and analyze the diagnostic information from the 
portable device. According to various aspects, analysis of the diagnostic 
information verifies successful installation and testing of vehicle software 
transferred from the portable device to vehicle processors, identifies software 
versions resident on the vehicle and related upgrade history for download and 
installation of an appropriate software upgrade, and/or diagnoses vehicle 
problems in accordance with sensed vehicle conditions and predetermined fault 
detection criteria. 

[0005] Further areas of applicability of the present invention will 
become apparent from the detailed description provided hereinafter. It should be 
understood that the detailed description and specific examples, while indicating 
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the preferred embodiment of the invention, are intended for purposes of 
illustration only and are not intended to limit the scope of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0006] The present invention will become more fully understood from 

the detailed description and the accompanying drawings, wherein: 

[0007] Figure 1 is a combination functional block and entity relationship 

diagram illustrating the vehicle and the vehicle software installation, upgrade, and 

diagnostic system according to the present invention; and 

[0008] Figure 2 is a flow diagram illustrating the vehicle software 

installation, upgrade, and diagnostic method according to the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0009] The following description of the preferred embodiment(s) is 

merely exemplary in nature and is in no way intended to limit the invention, its 

application, or uses. 

[0010] Referring to Figure 1, the vehicle 10 according to the present 
invention has an open architecture communications port 12A in communication 
with an interface processor 14. The open architecture communications port 12A 
is selected based on high speed, low price, and compatibility with inexpensive 
and commonly available processors. The present invention leverages the high 
speed and low cost of the port along with its compatibility to widely deployed and 
available personal computers. Thus, the selection of the specific port may, for 
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example, be matched to the most common port being deployed with personal 
computers. A typical and currently preferred example is the conventional 
universal serial bus (USB) port. However, this port could instead be replaced by 
other yet-to-be-designed standard interfaces. Alternative ports could be firewire 
or any future ports not yet widely in use. The USB or other port is provided to the 
vehicle and may be located in any convenient location. For example, the port 
12A may be located underneath the dash board on the driver's side of the 
vehicle. The port 12A is preferably mounted so that the port 12A remains hidden 
from everyday view, and yet is easily accessible without difficulty in locating or 
reaching the port 12A. The port may be added onto to the vehicle in addition to 
the conventional ALDL computer port on that kind of vehicle. Ultimately, 
however, the port is intended to become the only such external port on the 
vehicle. The possibility of having two data ports is offered only to provide a 
graceful transition in the deployment of the invention. 

[001 1] The interface processor 14 is connected to a system bus of the 
vehicle, and is adapted to load software received over the port 12A onto multiple 
processors 16A-16C that are also connected to the system bus. For example, 
interface processor 14 may be adapted to parallel flash program multiple 
processors 16A-16C using a frame interleaving technique. It is envisioned that a 
portable memory device 18 is employed to communicate vehicle software 20 to 
interface processor 14. Thus, interface processor 14 has the bootstrapping 
software necessary to utilize portable memory device 18. In a preferred 
embodiment, portable memory device is selected based on speed, capacity, 
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price, availability, and ability to interface with the port 12A. Therefore, portable 
memory device corresponds to a USB flash disk in a currently preferred 
embodiment where port 12A is a USB port. These disks are currently available 
in very large data capacities (64MB, 128MB, 256MB, 512MB). Also, these 
devices are very inexpensive relative to storage capacity. For example, 128MB 
of storage space may be purchased in single quantity for under thirty dollars, and 
the disk fits into a small package the size of a small cigarette lighter. The USB 
flash memory disks are further extremely compatible with current personal 
computers. For example, a user can typically plug a USB flash disk into a USB 
port on any reasonably current PC or Macintosh computer and the disk will self 
mount. Special software is not usually required at all. Thus, the present 
invention can effectively employ a standard off-the-shelf USB flash disk or 
equivalent. All of the special handshaking software is similarly integrated into the 
vehicle interface processor's 14 initial memory. Thus, interface processor's 14 
bootstrapping software corresponds to a driver that supports a USB flash 
memory device in a currently preferred embodiment. However, it is envisioned 
that other types of memory devices may be employed with the present invention 
as new types of memory devices and/or ports become available and market 
forces change. 

[0012] The present invention reduces price and increases speed and 
convenience in vehicle assembly, upgrade, and repair procedures by utilizing 
portable memory device 18 to provide a convenient, high speed, low cost 
mechanism for transferring vehicle software 20 and diagnostic information 22 
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between onboard vehicle processors and external processor 24. As a result, an 
expensive, portable, dedicated external processor does not have to be provided 
to each vehicle on the line during vehicle assembly. Instead, external processor 
24 may load vehicle software 20A onto device 18 via open architecture 
communications port 12B of external processor 24 based on the type of vehicle 
10. It is envisioned that external processor 24 may maintain a carousel of 
devices 18 as vehicles 10 approach on an assembly line during an assembly 
process 26. Thus, it is only necessary to have one external processor on the 
assembly line, with several inexpensive, portable memory devices 18. 

[0013] It is envisioned that an operator disconnects the next portable 
memory device 18 from external processor 24 and reconnects it to the port 12A 
of the vehicle 10. Then, as the vehicle 10 either remains in place or moves down 
the assembly line, interface processor 14 loads the software 20 onto the multiple 
processors 16A-16C. It is envisioned that the files of software 20 may be 
encrypted such that only the interface processor 14 program on-board a target 
vehicle 10 would be able to access the software and install it. It is also 
envisioned that software for multiple types of vehicles may be stored on one falsh 
disk, and that interface processor 14 may be adapted to identify the and load the 
appropriate files based on vehicle type. The multiple processors are adapted to 
automatically test the newly installed software 20 and transmit test results as 
diagnostic information 22 to interface processor 14. The testing function may be 
resident on the multiple processors as a result of installation of software 20, or it 
may be a function of software already resident on the multiple processors 16A- 
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16C. In turn, interface processor 14 is adapted to transfer the diagnostic 
information 22 embodying the test results to the portable memory device 18. 

[0014] It is also envisioned that, once the testing has finished, an 
operator disconnects the portable memory device 18 from the port 12A of the 
vehicle and reconnects it to the port 12B of the external processor 24. It is 
further envisioned that external processor 24 may in actuality be two separate 
processors in different locations on the assembly line that together from the 
external processor 24. Thus, external processor 24 accesses the diagnostic 
information 22 on the portable memory device 18 and uses diagnostic 
information analysis module 28 to verify that the software installation and testing 
procedure was successful. This verification 30 is provided as feedback to the 
assembly process 26. 

[0015] Dealers and other software, upgrade service providers similarly 
benefit from the ability to employ a personal computer or equivalent as an 
external processor 24 to provide upgrades to the vehicle 10 using a portable 
memory device 18. At the least, the need is eliminated for specialized, handheld 
devices that network with a server and are capable of interfacing with the ALDL. 
Thus, it is envisioned that an operator transfers a diagnostic program to the 
device 18 from the external processor 24 that is designed to determine what type 
of software is resident on the multiple processors 16A-16C as well as the entire 
software upgrade history. Then, the operator disconnects the memory device 18 
from the external processor 24 and reconnects it to the vehicle 10. Interface 
processor 14 responds by communicating the software 20 to the multiple 
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processors 16A-16C, which respond by writing out via interface processor 14 to 
the device 18 diagnostic information 22 indicating their software versions and 
update history. It is envisioned, however, that this function may be equivalently 
accomplished by allowing interface processor 14 to maintain a record of software 
installations and to provide the information to the device 18 upon request. 

[0016] Once the diagnostic information 22 is obtained, the operator 
disconnects the device 18 from the vehicle and reconnects it to the external 
processor 24. In turn, external processor 24 sends a query 32 over 
communications system 34, such as the Internet, to a manufacturer's server 36. 
The query 32 preferably indicates the vehicle type, software versions, and update 
history so that the server 36 can determine an appropriate software upgrade 20B 
and communicate it to the external processor 24. Then, external processor 24 
stores the new software on the device 18, and the operator essentially follows 
the same procedure as in the assembly process to install the software upgrade 
on the vehicle. It is envisioned that the appropriate software update may 
equivalently be identified by the external processor 24, rather than the server 36, 
so that query 32 merely needs to identify the needed upgrade to server 36. It is 
also envisioned that processor 24 may store and acquire the upgrades locally. It 
is further envisioned that the results of the software test may be communicated 
back to the manufacturer server 36. Appropriate encryption and security codes 
are preferably employed to prevent people other than authorized service 
providers from performing this function. 
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[001 7] Dealers and other repair services providers also benefit from the 
ability to use the portable memory device to diagnose problems with the vehicle 
10. In particular, repair service providers may dispense with expensive, 
specialized hand-held devices having ALDL connection capability. Instead, the 
diagnostic information 22 resulting from on-board vehicle fault detection can be 
transferred to external processor 24 for analysis via portable memory device 18. 
As a result, the same kind of open architecture port 12A on the vehicle and the 
same kind of portable memory device 18 may be used to extract diagnostic 
information from the vehicle's on-board computers for diagnosing problems. In 
the preferred embodiment, a flash disk would be preset via a standard PC to 
initiate a diagnosis function with the on-board multiple processors 16A-16C to 
generate and/or acquire pre-generated fault detection results based on sensed 
vehicle conditions and predetermined fault detection criteria. The on-board 
multiple processors 16A-16C write out all the diagnostic information into the flash 
disk via the interface processor 14. The flash disk is then read out by a standard 
personal computer being used as the external processor 24. Encryption and 
appropriate security codes may be employed to allow the manufacturer to control 
the process. The manufacturer might then sell the PC software to the dealership 
or other type of service group. As a result, the manufacturer retains control over 
the process, but still generates a profit from providing the advanced diagnostic 
capability to the end service provider. It is envisioned that some of the diagnostic 
information might be left readable by any PC as a normal text file, whereas the 
complex and more valuable information may only be interpreted by authorized 
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users having purchased the package. This solution completely eliminates the 
expensive, custom hardware typically employed to provide this kind of function. 
It also allows for a very user friendly display 38 of the fault detection results to the 
person using the tool. 

[0018] Referring now to Figure 2, the method according to the present 
invention typically begins with transferring vehicle software to the portable 
memory device via the external processor at step 40. It should be readily 
understood that the type of software stored on the device in step 40 may vary 
depending on the mode of operation of the present invention. For example, in an 
assembly mode, the vehicle software may correspond to supplemental software 
operable to adapt the multiple processors of the vehicle to properly operate their 
respective vehicle component systems. Also, in a first recursion of the method in 
an upgrade mode, hereinafter referred to as a pre-upgrade mode, the vehicle 
software may correspond to a driver, routine, or other trigger information adapted 
to cause interface processor 14 and/or multiple processors 16A-16C to write out 
their current software versions and entire upgrade history. Further, in a post- 
upgrade mode during a second recursion of the method, vehicle software may 
correspond to an upgrade to supplemental software operable to adapt the 
multiple processors of the vehicle to properly operate their respective vehicle 
component systems. Finally, in a repair mode, the vehicle software may 
correspond to a driver, routine, or other trigger information adapted to cause 
interface processor 14 and/or multiple processors 16A-16C to perform diagnostic 
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functions according to sensed vehicle conditions and predetermined fault 
detection criteria, and/or to write out previously generated fault detection results. 

[0019] At step 42, the method continues with establishing 
communication between the portable memory device and vehicle interface 
processor via the open architecture communications port of the vehicle. For 
example, this step typically involves disconnecting the portable memory device 
from the open architecture communications port of the external processor. Also, 
this step may be performed by an individual, such as a vehicle assembly line 
worker or repair and/or upgrade technician. Further, it is envisioned that this step 
may be performed by an automated system, such as a robot on an assembly 
line. 

[0020] At step 44, the vehicle software is transferred from the portable 
memory device to multiple processors of the vehicle via the interface processor 
of the vehicle. For example, in an assembly mode or post-upgrade mode, the 
interface processor loads identifies the appropriate files for each of the multiple 
processors and loads them onto the respective processors. Also, in a pre- 
upgrade mode or repair mode, the interface processor may load the files onto the 
multiple processors; alternatively, it is envisioned that the interface processor 
may equivalently access the software for the multiple processors. 

[0021] At step 46, diagnostic information is generated based on a new 
software autotest, current software versions and upgrade history, and/or fault 
detection results. For example, in an assembly mode or post-upgrade mode, the 
multiple processors autotest the newly installed software or software version to 
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generate the diagnostic information. Also, in a pre-update mode, the current 
software versions and upgrade history are accessed by the multiple processors 
and/or interface processor to generate the diagnostic information. Further, in a 
repair mode, fault detection results are generated by the multiple processors 
based on sensed vehicle conditions and predetermined fault detection criteria; 
equivalently, it is envisioned that pre-generated and stored fault detection results 
may be accessed to generate the diagnostic information. 

[0022] At step 48, the diagnostic information is transferred from the 
multiple processors to the portable memory device via the interface processor. 
For example, the multiple processors may write out to the portable memory 
device their auto-test results, fault detection results, and/or current software 
versions and upgrade history. Equivalently, it is envisioned that in a pre-upgrade 
or repair mode the interface processor may write out pre-stored information that 
may have been received from the multiple processors, or may have been stored 
during transfer to the multiple processors. 

[0023] At step 50, the method continues with establishing 
communication between the portable memory device and the external interface 
processor via the open architecture communications port of the external 
processor. For example, this step typically involves disconnecting the portable 
memory device from the open architecture communications port of the vehicle. 
Also, this step may be performed by an individual, such as a vehicle assembly 
line worker or repair and/or upgrade technician. Further, it is envisioned that this 
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step may be performed by an automated system, such as a robot on an 
assembly line. 

[0024] At step 52, the external processor analyzes the diagnostic 
information stored on the portable memory device. For example, in an assembly 
or post-update mode, the external processor verifies successful installation and 
testing of the newly installed software and provides feedback to an assembly or 
upgrade process at step 54. Also, in a pre-update mode, the external processor 
formulates a query for transmission over a communications network to a 
manufacturer's server, thereby identifying and downloading one or more 
appropriate software upgrades at step 56; equivalently, it is envisioned that the 
external processor may identify the appropriate upgrades based on the current 
software versions and update history, and/or access the appropriate upgrades on 
local memory. Further, in a repair mode external processor decrypts and 
displays fault detection results at step 58. Finally, the method ends after steps 
54 and 58, but not after step 56; instead, a second recursion is enjoined and the 
mode switches from pre-update to post-update. 

[0025] Those skilled in the art can now appreciate from the foregoing 
description that the broad teachings of the current invention can be implemented 
in a variety of forms. Therefore, while this invention has been described in 
connection with particular examples thereof, the true scope of the invention 
should not be so limited since other modifications will become apparent to the 
skilled practitioner upon a study of the drawings, the specification and the 
following claims. 
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